-
Notifications
You must be signed in to change notification settings - Fork 485
feat: add upgrade window check for environmentd image ref #34327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add upgrade window check for environmentd image ref #34327
Conversation
This commit introduces a new method to check if the current environmentd image reference is within the upgrade window of the last successful rollout. We default the image ref to the current version if status is not set.
edf7339 to
13a8710
Compare
doy-materialize
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conceptually this seems fine, but can we reuse the existing logic for checking the version compatibility? we already have an implementation of this in cloud via is_valid_upgrade_image_ref, and i think it'd be better to pull that code out to the materialize repo and use it in both places
f5b4577 to
b547b8f
Compare
|
@doy-materialize done in the latest commit and created a followup cloud PR https://github.com/MaterializeInc/cloud/pull/11901. More or less copied the code and tests. Two things:
|
The plan is to use this public static function in the Cloud repo. Borrows most of the same logic, but allows upgrades from/to dev versions.
b547b8f to
96da51f
Compare
| if next_version.major != active_version.major { | ||
| if next_version.major == 26 | ||
| && active_version.major == 0 | ||
| && active_version.minor == 164 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be 147
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(with a specific patch version)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, right, it should be both (i forgot about that since we weren't deploying those versions to cloud)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jun is fixing it: #34371
| (Version::new(0, 83, 0), Version::new(0, 83, 1)), | ||
| (Version::new(0, 83, 0), Version::new(0, 83, 2)), | ||
| (Version::new(0, 83, 2), Version::new(0, 83, 10)), | ||
| (Version::new(0, 164, 0), Version::new(26, 0, 0)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also 147 I think
This commit introduces a new method to check if the current environmentd image reference is within the upgrade window of the last successful rollout. We default the image ref to the current version if status is not set.
Not sure if this is the best way to solve this! One nice thing is we'll see the last version everytime we upgrade which can be useful.
An edge case is if the user's materialize CR status is already set, then it won't have
last_completed_rollout_environmentd_image_refuntil the next successful rollout. So hypothetically, users onv26.0.0can jump straight tov28.0.0if they didn't upgrade between then.We solve this by relaxing the check as much as possible, also in case of other false positives.
Motivation
Tips for reviewer
Checklist
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way), then it is tagged with aT-protolabel.